The advent of the Internet has facilitated the use of subscription services provided any number of subscribers. In a subscription processing system, relationships are maintained for subscribers with respect to specific subscriptions purchased, its associated services, specific payment instruments to be used for billing, specific payment methods to be used, etc. For every such customer, an entity called an account is maintained, along with the associated subscription, service, and payment instrument entities. It is essential that the system take all the necessary accounting actions on a periodic basis as the business demands. For example, every month, subscriber accounts need to be task-processed for charges, given any resources and charge adjustments, processed for cancellations, expirations or renewal, have services enabled, disabled, provisioned or de-provisioned, emails sent according to various events to keep the customers informed, etc. The system performs these tasks periodically (e.g., daily) to keep the state of the accounts in synchronism with the passage of time. In most cases, these account tasks must be performed in a certain order. Thus, a second task is dependent on first task, and requires the first task to be successfully completed before the second task can be completed.
Periodic processing of this inter-dependent set of tasks is what keeps the customer accounts consistent and up to date as defined by business processes. As indicated previously, it is important that the dependent tasks are performed in order and the dependency is strictly enforced. It is equally important for the business that processing be done for potentially millions of accounts/subscriptions on a daily basis in a reasonable amount of time, e.g., not more than 3-4 hours every day. This is important so that customer initiated actions (e.g., signups, self care), customer service representative (CSR) initiated support actions (e.g., credits, adjustments) and other system actions (e.g., payment processing) have accounts in a consistent state to work with. This also allows completing periodic processes during the lull period for other activities so that they do not compete with each other for system resources. Further, because of hardware, software, business or operational issues, at times periodic processes may not run regularly. As such, it is desired to have the capability to process multiple days worth of processing in a single day to recover.
Even though periodic processes are done during the lull period for other activities and it only takes 3-4 hours to complete them, other activities on the account cannot be blocked. Hence, a ‘catch-up process’ is provided that can bring this particular account to a consistent state on demand.
Thus, periodic processing of the tasks has at least the following requirements. First, the order and dependency of these tasks is required to be strictly enforced for a given customer account. Second, task processing for all needs to be completed in a reasonable amount of time, e.g., 3-4 hours. Third, there needs to be a way to bring an account to a consistent state on demand. One way to address the first requirement would be to visit each account and all of its associated subscriptions, payment instruments, etc., every day, and test whether the account needs processing for all the different related tasks. However, the first requirement has performance implications that can seriously jeopardize the second requirement. For example, if there are ten million accounts and fifteen related tasks, it would require processing to completion 150 million such tests each day. Even if only testing was being performed for the whole four hours, each test for each account would need to be completed in ninety-five microseconds. After performing through the 150 million tests, based on empirical evidence, approximately only one percent tests will result in actual processing work.
What is needed is an improved processing technique for handling large numbers of accounts.